CSI Enterprise Security Framework (CSI-ESF)

1. Framework mandate

CSI-ESF governs CSI's internal security practice and reusable client security services. It is subordinate to CSI Nexus Blueprint v1.0 and follows the fixed hierarchy: Blueprint → Playbooks → Standards → SOPs → Templates → Reference Library → Decision Book.

Operating position: IT Infrastructure is the foundation, AI is the value-expansion layer, Cyber Security is the protection layer, and Managed Services provide ongoing reliability.

Security principle: Solve the business problem first. Apply technology only after assets, dependencies, threats, impact, risk appetite, operational capacity and recovery needs are understood.

2. Scope

The framework supports:

• Security governance, architecture and risk management
• Client assessment, remediation and assurance
• Secure infrastructure and service implementation
• Managed monitoring and vulnerability management
• Incident readiness and coordinated response
• Compliance mapping and evidence management
• AI, API, application, cloud, container and data security
• Security awareness, supplier assurance and physical safeguards

3. Guardrails

• CSI does not certify that an environment is breach-proof or vulnerability-free.
• Security conclusions are point-in-time and limited to agreed scope and available evidence.
• Material changes affecting availability, security, data, licensing or cost require client approval.
• Intrusive testing, exploit execution, malware handling, forensic acquisition and 24×7 response commitments require separately approved capability, contract and qualified personnel.
• Every exception must state owner, rationale, risk, compensating control, approver and expiry or review date.
• Client credentials and sensitive evidence must not be stored in general documentation pages.

4. Security practice architecture

flowchart TD
    A["Business objectives and obligations"] --> B["Assets, data and dependencies"]
    B --> C["Threat and risk assessment"]
    C --> D["Control design and architecture"]
    D --> E["Implementation and validation"]
    E --> F["Monitoring and response"]
    F --> G["Evidence, metrics and improvement"]
    G --> C

5. CSI-ESF pillars

6. Control model

Each CSI-ESF control must have:

• Unique control ID and accountable owner
• Business outcome and risk addressed
• Applicability and implementation guidance
• Required evidence and validation method
• Control frequency and review trigger
• Mapped technologies and reference frameworks
• Exception method and residual-risk decision
• Client-facing explanation without unsupported guarantees

Control status is Not Assessed, Not Applicable, Gap, Partially Implemented, Implemented, Verified, or Exception Approved. A control is not Verified merely because a setting exists; evidence must show that it is operating as intended.

7. Risk method

Risk score = Likelihood (1–5) × Impact (1–5).

Impact considers confidentiality, integrity, availability, safety, legal/regulatory exposure, financial loss, operational disruption and reputation. Likelihood considers exposure, exploitability, threat activity, control strength and prior events. Residual risk is scored after confirmed controls.

8. Maturity model

CSI recommendations must be proportionate to business size, risk, capability and budget. Level 5 is not automatically the target for every client.

9. Client security lifecycle

flowchart TD
    A["Qualify and authorize"] --> B["Discover and scope"]
    B --> C["Assess and collect evidence"]
    C --> D["Rate risk and agree priorities"]
    D --> E["Remediate and validate"]
    E --> F["Handover and accept residual risk"]
    F --> G["Monitor and review"]
    G --> B

Every engagement produces an authorization record, scope, asset/evidence references, findings, treatment plan, validation result, residual-risk decision and management summary.

10. Evidence standard

Acceptable evidence includes approved configurations, system exports, time-stamped screenshots, logs, tickets, interviews corroborated by technical evidence, restore tests, alert tests and signed decisions. Evidence must record source, collector, collection date, scope, integrity considerations, retention and access restrictions.

11. Document pattern

Every domain document uses a proportional modular pattern:

1. Executive and business context
2. Risks, mistakes and architecture
3. Policy, standard and baseline requirements
4. Procedure, SOP and deployment guidance
5. Engineer, client and audit checklists
6. Assessment, maturity and risk criteria
7. Monitoring, incident handling and troubleshooting
8. Examples, FAQ, lifecycle and future improvements

Long technical instructions remain in SOPs and implementation guides; the CSI-ESF blueprint stays concise and executive-friendly.

12. Framework mapping

CSI-ESF uses cross-mapping rather than duplicating external standards:

• NIST Cybersecurity Framework 2.0 for outcome structure and executive communication
• CIS Controls v8.1 and CIS Benchmarks for prioritized safeguards and hardening
• ISO/IEC 27001:2022 and ISO/IEC 27002:2022 for management-system and control alignment
• MITRE ATT&CK for threat behavior, detection and validation
• Applicable Indian legal, contractual and CERT-In obligations, confirmed for each engagement with qualified legal or compliance owners

13. Governance and review

Framework owner: CSI CISO / Security Practice Owner

Architecture authority: CSI Nexus Architect

Operational owners: named per domain, engagement and control

Review cycle: Annual, plus triggered review after material incidents, major technology changes, relevant legal/regulatory change, new service launch or repeated control failure.

All controlled documents follow Draft → Under Review → Approved → Superseded → Archived. Previous approved versions are preserved.

14. Initial capability boundary

CSI's initial production-ready security offering is:

• Security assessment and risk-based reporting
• Windows, Linux, server, firewall, network and remote-access hardening
• Authorized vulnerability assessment and remediation validation
• Backup and ransomware resilience review
• Wazuh-oriented monitoring pilots and managed monitoring with explicit service hours
• Security documentation, awareness and incident-readiness exercises

Advanced offensive security, forensic acquisition, malware analysis, red teaming and 24×7 SOC/incident-response guarantees remain gated until CSI has validated tools, trained personnel, legal terms, laboratory evidence and operational capacity.

15. Success measures

• Percentage of in-scope assets with owner and support status
• MFA and privileged-access coverage
• Critical/high findings overdue
• Patch and vulnerability SLA performance
• Endpoint, log and backup monitoring coverage
• Successful restore and incident exercise rate
• Mean time to acknowledge and contain within contracted service hours
• Approved exceptions past expiry
• Evidence completeness and control verification rate
• Repeat findings and residual-risk acceptance ageing

16. Immediate build sequence

1. Approve CSI-ESF governance, scope, risk and evidence standards.
2. Build the domain/control catalogue and reusable document modules.
3. Build authorization, assessment, finding, evidence, treatment and sign-off templates.
4. Validate controls in the CSI security lab.
5. Run an internal assessment and close critical gaps.
6. Run one controlled client pilot.
7. Review evidence, commercial boundaries and service readiness before scale.

Document ID: CSI-BP-SEC-0001

Version: 1.0 Draft

Owner: CSI CISO / Security Practice Owner

Created: 26 July 2026

Next scheduled review: 26 July 2027

Classification: CSI Internal — Controlled Framework

CSI-ESF Control Catalogue

CSI-ESF Findings & Risks

CSI-ESF Evidence Register

CSI-ESF Domain Register